What are difficulties about migrating to a distributed AGILE framework?
Now that you have an idea of what distributed AGILE development really is, and what it stands for, the question comes up, how hard is it to actually move towards such a framework? Is the overhead cost not worth it? Let's find out! The biggest challenges in migrating to distributed AGILE come from the organisational perspective. AGILE makes the lives of the developers easy but not necessarily that of the organization. If an organization is monolithic, there will need to be a overhaul in terms of the approach to software development and the way they interact with clients and approach deadlines. They will have to move to a less autocratic style of management and reduce the centralized management approach and give higher power to developers. Important decisions regarding the product will be made by the team of developers instead. Of course with this shift in responsibility comes the added requirement that the developers are capable of taking on leadership and making decisions. Management related challenges: This requires a mindset change from the top in terms of organizational culture or style of management. Culture plays a vital role in the functioning of an organization in terms of decision-making and communication channels. Agile software development requires that the company shifts from a more controlling culture to a laissez-faire approach. The problem is mindsets are hard to remove easily, and thus, this could prove to be a thorn to management. Also, to change one's management style, it could be that the managers may need additional training. This could prove costly for big corporations who have teams in different countries. Retraining workers could end up taking more time and capital than expected. There could also be issues communicating vital cultural issues through video channels. Thus, it may be recommended to have a big organisation wide meeting at the start of a new quarter or year to ingrain these ideas into the various teams. In terms of the shape of the organisation, decision-making is sent out to the different developers and requires more collaboration between the central management and the developers. This requires a shift in the job of the project leaders; they will need to be the coordinators between higher management and the developers. Systems will also need to change in how they reward workers as now, there is a bigger emphasis on the collaborative spirit than previously. People related challenges: To be effective in a team requires different skills to being effective in a traditional work environment setting. There has to be better communication, more efficient dividing-up of tasks and more competent workers overall. To program alone is relatively easy but to program in a distributed group environment and make your code readable by a group that lives elsewhere is much harder. This could take training from the company again to make workers more efficient. It will also be harder to hire talent as they will be looking for skills that are difficult to test and not programming related. Distributed AGILE also encourages the client to be participating in the decisions of the team and the product so they have a better say in the iterations of the product. This could be difficult as the company would need to send someone with a technical background instead of someone completely new. In some countries, the bar of talent is different than that of the onshore company. For example, most American companies that do offshore programming work find that the quality is lacking and the offshore company ends up taking more time as well sometimes. This could compound costs. Thus, to be AGILE in a distributed setting requires more careful planning and qualification tests from higher management to ensure they have the quality needed to get the job done. Process related challenges: To participate in AGILE, there has to be a shift in terms of the overall flexibility in project management. Since the end product is built in iterations, there is a lot more uncertainty as to what the end goal really is. In a traditional setting, there is a clear end target and the team works towards it for a specified time period. However, in AGILE, since the development is more iteration based and the client is in constant interaction with the developers, ideas change rapidly. This leads to a different workflow process in the company. AGILE methodologies are more uncertain and require adaptive minds. For most, this could lead to problems again in the communication channels used, the problem-solving thought required and the speed of thought required. This is arguably where the biggest changes have to occur. The company has to ensure that there are shorter sprints, better communication channels and good ways to progress. The project will slowly be distributed to the various channels making it harder to communicate and making transparency throughout the company difficult as well. Technology related challenges: In distributed AGILE, there is an emphasis on the latest and most relevant technology that will move the company forward, more so than that in AGILE in fact. This comes about because of the fact there are a higher number of offshore people who need support. Thus, bigger tasks have to be broken down to small, digestible amounts that all parties can follow with and complete easily. There also is a change in the technologies used because the development is iteration based. Testing is of paramount importance; since work moves at a much faster rate with frequent checks, there is a need for a clear testing framework. There also have to be suitable version-control systems that support this rapid software development. Overall, there are many facets a company must look at when migrating to a distributed AGILE framework. The most important question is whether this process will improve the company in the long term and the answer is almost always a resounding yes. However, having said that, it is important to keep to a company's values and not change their goals completely to align with all of distributed AGILE's principles. Most companies end up using an AGILE framework mixed in with their own company procedures to make it work for them. This is entirely possible and a great option for any company which does not want to completely adhere to distributed AGILE's principles. References: # Cavaleri, S. and Obloj, K. Management Systems: A Global Perspective. Wadsworth Publishing Company, CA, 1993. # Cockburn, A. and Highsmith, J. Agile software development: The business of innovation. IEEE Computer (Sept. 2001), 120–122 # Cockburn, A. and Highsmith, J. Agile software development 2: The people factor. IEEE Computer (Nov. 2001) # Nerur, Sridhar, RadhaKanta Mahapatra, and George Mangalaraj. "Challenges of migrating to agile methodologies." Communications of the ACM 48.5 (2005): 72-78.